1. Field of the Invention
The present invention generally relates to authentication and/or ciphering electronic circuits, for example, contained in smart cards.
An example of application of the present invention relates to bank cards, the main application of which is to be used as means of payment. In this application, the present invention more specifically relates to so-called EMV smart cards (Europay MasterCard Visa) having a standardized operation and, among said cards, to cards fulfilling standards EMV 4.0 and the subsequent applying to smart cards provided with an asymmetrical ciphering function (especially RSA).
2. Discussion of the Related Art
FIG. 1 very schematically shows an example of a smart card of the type to which the present invention applies. An integrated circuit chip 1 is inserted in a plastic card 2 and is connected to metal contacts 3 to communicate with a card reader, not shown. In applications to bank cards, the card communicates through contacts 3 with the reader but may also be provided with a contactless communication system, for example, for other applications.
FIG. 2 very schematically shows in the form of blocks, components of an integrated circuit 1 forming a chip of a card 2 of FIG. 1. Circuit or chip 1 comprises a central processing unit 11 (CPU), one or several non-volatile storage elements 12 (NVM), one or several volatile storage elements 13 (for example, of RAM or register type). The different components of chip 1 communicate together and with an input/output device 14 (I/O) connected to contacts 3 over one or several address and control data buses 15.
The present invention applies to electronic circuits capable of implementing an asymmetrical ciphering algorithm (also called public key algorithm). This functionality is illustrated in FIG. 2 by the presence of a block 16 (RSA FCT) showing that the chip integrates an RSA-type function (hardware and/or software). The RSA algorithm is an asymmetrical algorithm consisting of a modular exponentiation of the message to be ciphered by using the key as an exponent.
In public key architectures, once the pair of public and private keys has been generated, the public key is certified by a certification authority (CA) or trusted third party.
The private key of a transmitting entity is used to sign a message, that is, generate a set of bits called the digital signature, which is a function of the actual message, and of the private key of the entity. The receiver of a message comprising a digital signature can check the signature by using the public key of the transmitting entity. This enables him to be sure of the origin of the message. The receiver must thus have a copy of the transmitter's public key to be able to check that the message effectively originates from the concerned transmitter.
Other public key systems not only transmit with a clear message a signature used to authenticate the transmitter, but also cipher the actual message. The private key of the receiver is then used for him to decode (decipher) the transmitted message, ciphered with the copy of his public key.
The certification authority is used to provide a user with a certificate (binary message) containing the public key of this user associated (most often, concatenated) with other data relating to this user (for example, an identifier of the user, a validity duration of the key, etc.) and with a digital signature. The digital signature attached to the certificate is calculated with the private key of the certification authority. The certification authority provides its public key separately (generally, by other secure means) to a group of concerned users. Any user in possession of a copy of the public key of this certification authority can then check all the certificates generated by this authority (check the signature) and thus obtain trustworthy copies of public keys of other users.
In the application to EMV bank cards, the certification authority is the bank system which generates certificates for all users (banking establishments) by signing their respective public keys (generally by using different keys per card assembly and/or according to the banking establishments). The bank system then provides its public key(s) to the payment terminals (acquirers) to enable them, when a card is introduced into the terminal, to check the certificate coming along with the public key of the card and obtain a copy (certified) of this public key that he may trust. In certain cases, the certificates contain data only (no key).
Symmetrical ciphering mechanisms (with secret keys) are generally also provided and are used to authenticate the data exchanged between the card and the transmitting bank, independently from the authentication performed by the asymmetrical mechanism. In a symmetrical mechanism, the same key is used to cipher and decipher the data, and the receiver needs the secret key of the transmitter. The transmission of this key may use an asymmetrical ciphering.
Most often, the card user is authenticated by the card by introduction of its confidential code (PIN code). The PIN code is transmitted to the user by other means (generally, a mail) and only the card issuer knows it.
In recent systems to which the present invention more specifically applies, when a terminal needs to authenticate a card, it uses a so-called dynamic data authentication (DDA) which consists of requiring from the card to sign a variable message (pseudo-randomly generated) with its private key. This enables the terminal having obtained the public key of the card by decoding its certificate to check that it effectively is the right card and not a fake card.
Bank cards of this type are more and more often capable of processing other applications than the bank application for which they are initially intended. These may be, for example account balance consultations, bank transactions other than a payment, etc. Such other applications are not necessarily linked to the bank system. These may be, for example, loyalty card, transportation card applications, etc.
For the card to be able to implement several applications requires distinct authentication mechanisms between the EMV bank applications and the others. Such authentication mechanisms use asymmetrical ciphering algorithms (public key systems) and are often designated as PKI applications (public key infrastructure).
More generally, an electronic circuit of authentication of a smart card or the like more and more often be able to authenticate the card for different applications, not necessarily managed by the same application provider.
This requires that the smart card contain not only the keys necessary to its authentication for a main application (for example, the EMV application) but also keys for each other secondary application (for example, PKI) that it is likely to support.
A problem which is posed is the introduction, into the card (more specifically into its integrated circuit), of such keys, necessary afterwards for the authentication by the asymmetrical ciphering algorithm (RSA or other). In particular, the request of a certificate by the card from the certification authority of the PKI application should be secured, that is, it should be guaranteed that the public key received by the PKI certification authority does belong to the holder of the card requiring a certificate.
A first solution would be to perform this checking on manufacturing by generating the keys in the card during the so-called mass customization. This solution can, however, not be envisaged due to the time required to generate RSA keys (several seconds per key for 1024-bit keys). Further, after generation of the keys, it would be necessary to complete secure communications with as many trusted third parties as there are PKI applications, in addition to that required by the EMV application, to obtain the corresponding certificates which must be stored in the card.
Further, card holders generally have a subjective impression that the fact for the authentication keys to be generated after manufacturing (while they are in possession of the card) makes the procedure more secure.
FIG. 3 very schematically illustrates in the form of blocks a conventional solution adapted to the generation of secondary application keys during the card lifetime. This solution consists of using a trustworthy terminal (ATM) 20 able to implement various control mechanisms, for example, the checking of the identifier of card 2, the checking of its PIN code, etc. to authenticate the card holder and the connection between the key and this holder. Terminal 20 then communicates over a secure connection with the trusted third party 30 (CA) of the PKI application to obtain the certificates.
A disadvantage of such a solution is that it requires to the card holder who wants to customize a new application on his card to go to a specific location having so-called trustworthy terminals.
It would be desirable to be able to customize PKI applications in smart cards by means of conventional readers (for example, of the type of a card reader equipping a personal computer). Different control mechanisms must then be combined but the problem that the terminal (personal computer) cannot be considered as trustworthy is then posed.
It could have been devised to use a single-use specific code (ONE TIME code) introduced into the card during the customization and used by the card holder like a one-time PIN code. A disadvantage of such a solution is its implementation cost, since it would require placing, in each card, a specific program for a single use.